Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/cat/cat-minutes-91jul.txt

Text File | 1993-02-17 | 10.5 KB | 250 lines

CURRENT_MEETING_REPORT_


Reported by John Linn/DEC

CAT Minutes

The Common Authentication Technology Working Group met for two sessions
in Atlanta, and held discussions building on the three Internet Drafts
issued on behalf of the group in advance of the meeting.  John Linn led
a discussion on CAT and GSS-API concepts, and Jeff Schiller and Charlie
Kaufman gave presentations on implementations of CAT atop (respectively)
Kerberos V5 and SPX mechanisms; slides from these presentations will be
submitted along with these minutes for inclusion in the IETF
Proceedings.  Representatives from some protocol Working Groups were
available to comment on issues related to integration and use of CAT
within their protocols.

CAT concepts were generally well received.  Some areas of potential
refinement and discussion were raised, and discussions are expected to
continue on the CAT mailing list.  One key area of technical discussion
was the interrelationship among CAT, underlying mechanisms, and
alternative naming architectures; a related area was alternative types
of authenticated principals (users, hosts, processes) and means for
their distinction.  It was noted that the fact of implementation of a
particular mechanism in support of CAT should not be taken as IETF
endorsement of the strength of that mechanism.  It was also noted that
multiple mechanisms may in principle be incorporated beneath a single
GSS-layer implementation, though no such implementations have yet been
developed.

Identification of Shared Mechanism

One major discussion topic was the question of how to identify a CAT
mechanism which is shared with a peer CAT system.  Options include
combinations of negotiation, directory entries, configuration data, and
user/caller input; it was agreed that CAT should seek to make suitable
determinations internally where possible so as to ease burdens on its
callers and to avoid replicating common security-oriented features
separately within a variety of caller protocols.  This implies, for
example, that CAT callers' requests for the ``default'' mechanism type
could result in exchange of tokens in order to resolve a common
mechanism; the feasibility of such a scheme warrants investigation.
Whenever negotiation is used to establish a mechanism, it should be
carried out against an acceptable set defined by configuration data
and/or caller input, to prevent blind acceptance of authentication
schemes weaker than those intended by a CAT peer.

Naming Issues

As the Internet evolves to a multi-protocol environment, it also evolves
to an environment where multiple naming architectures must coexist.
Prominent examples include DNS names for hosts, mailbox identifiers for
users, and X.500 Distinguished Names.  This variation causes problems in

                                   1





many areas of technology (and is engendering discussion in several parts
of the IETF and the TSIG, as well as other groups), and security is
among those bitten.

Since authentication mechanisms typically authenticate principals in
conjunction with name forms native to those mechanisms, mismatches are
likely to emerge when CAT callers oriented to operation in particular
naming environments are served by CAT mechanisms employing different
native forms.  It was agreed that CAT would benefit from broader
IETF-defined approaches to handle such mismatches; in the interim,
mechanism designers will have to anticipate, observe, and provide
case-by-case resolutions to specific problems.  In the interests of
portability between alternative mechanisms both capable of
authenticating a common name format, it was observed to be preferable
for identification of the mechanism used to authenticate a name to be
carried in a separate parameter rather than being encoded within the
name itself.

Mechanism Discussions

(See also presentation slides.)

Jeff Schiller led a discussion on Kerberos GSS-API implementation.  MIT
believes that it is appropriate for all services which run as root on a
given host to use a common set of verifier credentials in /etc/srvtab;
the Athena DISCUSS service has a different identity with credentials in
a different file.  Distinction between client and server principals is
made based on examination of names.

Jeff also observed that MIT intends to relinquish control of the
Kerberos V5 specification (distributed to Internet-Drafts before the
meeting) to the CAT Working Group for evolution and standards-track
progression, and cited Ted Tso and Cliff Neuman as additional relevant
contacts.  A Kerberos V4 specification will also be submitted as an
informational RFC.

Charlie Kaufman led a discussion on SPX GSS-API implementation,
emphasizing implementors' agreements made in order to enable application
portability (though not the broader issue of interoperability) between
Kerberos and SPX. Internal names were accepted to be opaque (preserving
flexibility for mechanism implementors), although use of a standardized
format at this level could offer value if callers were positioned to use
the same format across other interfaces besides the GSS-API. The target
applications chosen to validate the portability concept were Telnet and
rlogin; since DNS-style textual names are native to these applications,
conflicts with SPX's use and certification of X.500 DNs needed to be
resolved.

Protocol Integration Issues

It was observed that error cases resulting from inability to process a
transferred and received token cannot always be reflected to a CAT peer
before that peer believes that the context establishment sequence is
complete; for CAT callers to be assured that their tokens have been

                                   2





successfully processed on receipt, mutual authentication must be
performed.  Error-indicating tokens received after context establishment
is complete can still be processed, by being passed to a different
primitive (process_context_token).  It was observed that it might be
preferable to incorporate more messages in mechanisms' context
establishment sequences so that COMPLETE status is never returned before
positive acknowledgment by the peer.  No conclusive decision was made on
this issue.

The Telnet Working Group plans to issue the Telnet authentication option
as an experimental RFC; it was anticipated that migration to CAT as an
additional Telnet-visible type (which would likely supplant other
Telnet-visible type indicators over time) would be appropriate.
Terminal servers cannot be assumed to maintain configuration data
corresponding to arbitrary ``walk-up'' users, so raise special issues
with regards to integration with user interfaces and CAT infrastructure.

The Network Printing Working Group is seeking to employ CAT. Discussion
indicated that different types of authentication semantics (users,
hosts, daemon processes) would be most appropriate in different
circumstances; unfortunately, prioritized needs for the different
alternatives were not available.

Possible CAT applications arise in the Network News Transport Protocol
(NNTP). Primary requirement areas raised at the CAT meeting include
host-granularity authentication for sessions between NNTP peers and
user-granularity authentication for individuals associated with NNTP
newsreaders.  Ted Tso is engaging in additional discussion with the NNTP
group regarding potential CAT usage.

The LIST group may wish to employ CAT-based authentication for those
cases where list maintenance commands are transferred across on-line
connections rather than within messages.

Possible Extension Areas

Various candidate CAT extension areas were discussed, and are likely to
be discussed further on the CAT mailing list.

Means for provision of long-term signature capabilities were considered
only briefly, in part because of unclear requirements for
non-repudiation services outside the messaging paradigm.  The following
observations were noted:


  1. Since such signatures are intended to be validatable over an
     extended period and by other than the single peer associated with a
     context, such extensions are not well suited to modeling via the
     Quality-of-Protection (QOP) parameters to existing GSS-API
     per-message protection primitives,

  2. That alternative primitives might utilize common credentials, and



                                   3





  3. That long-term signature capabilities would not likely be portable
     to other than public-key mechanisms.


Interest was expressed in making the set of intermediary entities which
had been involved in a CAT authentication visible to a caller,
presumably by providing means to extract such a name list from a
context's data structures.  It was unclear whether callers would be
likely to make use of such a list in a mechanism-independent manner.

We also discussed the idea of an overlay veneer
(``init_sec_context_stream()'') to provide CAT with a communications
path over which to pass tokens rather than returning the tokens for
caller manipulation and transfer, an extension facility which could
simplify integration of CAT-based authentication into certain caller
protocols.  Such an overlay would be analogous to Kerberos's send_auth
interface; follow-up mailing list discussion is anticipated.


David Bolen
David Borman             [e-mail]
Stephen Crocker          [e-mail]
Peter Deutsch
James Ellis              [e-mail]
Arlan Finestead          [e-mail]
James Galvin             [e-mail]
Joe Godsil               [e-mail]
Russ Hobby               [e-mail]
Alton Hoover
Ken Jones                konkord![e-mail]
Charles Kaufman          [e-mail]
Peter Kirstein           [e-mail]
Dale Land                [e-mail]
Eliot Lear               [e-mail]
John Linn                [e-mail]
Louis Mamakos            [e-mail]
Ellen McDermott          [e-mail]
Glenn McGregor           [e-mail]
Clifford Neuman          [e-mail]
Oscar Newkerk            [e-mail]
Richard Parker           [e-mail]
Geir Pedersen            [e-mail]
Mel Pleasant             [e-mail]
P. Rajaram               [e-mail]
Michael Reilly           [e-mail]
Jan Michael Rynning      [e-mail]
Jeffrey Schiller         [e-mail]
Robert Shirey            [e-mail]
Mark Sleeper             [e-mail]
Mark Stein               [e-mail]
Brad Strand              [e-mail]
Glenn Trewitt            [e-mail]
Theodore Tso
Preston Wilson           [e-mail]

                                   4








5